Large computing systems, such as, for example, enterprise resource planning (ERP) systems, may host applications or software systems, as well as one or more associated databases, to be accessed by one or more users or customers. Further, each database may include data for one or more “tenants,” each of which may be associated with a particular client or customer of the system. Generally, each tenant can access its specific data, but not the data of other tenants. The software systems may facilitate one or more business functions, such as sales, marketing, product development, finance, human resources, and the like. Periodically, the software systems, as well as the databases associated therewith, may be upgraded to provide additional functionality, to address previously discovered performance issues, or to satisfy other purposes.
During a software system upgrade, an associated database may need to be upgraded as well due to changes in the types of data being stored, the format or structure of the data, and for other reasons. In one type of upgrade procedure, a single downtime window is employed for all tenants of the database. During the downtime, all database tenants are prevented from executing the current software version to ensure that the data of the database is not being altered during the upgrade. The tenant data of the current database version associated with the current version of the system is then upgraded to a target version of the database associated with the upgraded version of the software. The target version of the software may then be initiated for use by the customers. This type of upgrade procedure is employed typically in large systems with one, or only a few, tenants, to avoid affecting a large number of clients or customers for a long time period. Also, as all database tenant are upgraded at the same time, and individual “fallback” position for each tenant in case of a failure in the upgrade procedure is not normally provided. Thus, a problem with the upgrading of one the tenants may cause a retry of the upgrade procedure for all tenants.
In an alternative upgrade procedure, an entirely separate software system and associated database for the upgraded software may be provided. As a result, each database tenant may be transported from the current database to the target database separately, as both the current and target software systems may be operating simultaneously. Accordingly, an unsuccessful upgrade of any tenant may be reversed, thus allowing the tenant to continue to operate with the older, current software system and database. To implement this alternative upgrade procedure, two separate software systems and databases are maintained for at least some period of time. As a result, all customer or tenant data in the database are moved from one separate software system and database to another, regardless of whether the data is actually reformatted or reconstructed as part of the upgrade.